[WIP] Channel renaming extension. by sadiepowell · Pull Request #308 · ircv3/ircv3-specifications

sadiepowell · 2017-06-03T23:48:01Z

jwheare

👍 looks good. Maybe a non normative suggestion for servers to optionally apply temp forwarding from old chan to new chan to aid migration for users offline when the rename happened?

Is there a reference implementation for inspircd?

sadiepowell · 2017-06-04T10:31:11Z

Is there a reference implementation for inspircd?

There will be soon™. I just need to finish up a few things.

Zarthus · 2017-06-04T13:55:22Z

I don't see anything wrong, but I feel like rename is kind of generic of a keyword and won't really scale if you ever expand this idea. Let's say in the future you want to tack on the ability to archive (read-only) channels or close them down entirely. To be consistent with this format you'd need to reserve ARCHIVE and CLOSE, and /close already is an alias in many IRC clients.

I would probably do something like CHGCHAN (consistent with CHGHOST) or CHANRENAME, and I agree it is bikeshedding to some degree, but it's something that should at least be mentioned if you want to expand this idea to the degree Slack already has.

extensions/rename.md

Zarthus · 2017-06-04T13:58:46Z

Would it be possible to rename a channel from #chan to !chan? On some IRCds this means the channel serves a different function and clients may not wish to adhere to channel redirection (let's say #chan is a normal channel and !chan is opless mode which does not support founders).

Awfully ircd specific, but perhaps worth mentioning in a security or nonnormative section.

RyanSquared · 2017-06-05T00:05:45Z

Would it be possible to rename a channel from #chan to !chan?

To quote @SaberUK from IRC:

2017-06-04 09:23:12 SaberUK Zarthus: i'm thinking it should be a SHOULD NOT for servers

DanielOaks · 2017-06-05T02:14:00Z

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Should they send both ERR_CHANOPRIVSNEEDED followed by ERR_CANNOTRENAME, and similar for ERR_CHANNAMEINUSE. It seems appealing for clients/bots to be able to expect either a RENAME command or a ERR_CANNOTRENAME numeric in response, to know for sure whether it failed or succeeded.

Plays into the questions brought up in IRC around how to alert for errors with specific commands in general going forward. I'm just using the existing ERR_UNKNOWNERROR in my hacked-up impl, which includes the original sent command in it.

DanielOaks · 2017-06-05T02:18:54Z

extensions/rename.md

+Server implementations MUST implement a fallback method for legacy clients.
+This method SHOULD involve sending a fake `PART` message for the old channel
+name and a `JOIN` message for the new channel name as well as a `MODE` message
+to restore any prefix modes that the legacy client has applied to it.


It seems like this should be specified in greater detail as a normative thing. Should the PART message be the reason specified by the sending user, and include the name of the user who sent the rename request? It seems like they should also send the NAMES message and TOPIC ones if they normally send those, or it could even say something like 'just send everything as though it were a regular channel join' perhaps?

Specifying this in more detail might help reduce any possible confusion around here, and make sure servers stay consistent with how they implement it.

As with the MODE for sending prefix modes, what about modes that exist otherwise, such as prefix ones such as +b and +f (ban and forward) and all other possible channel modes?

I'd probably just send everything you'd normally send on a client joining the channel. Name lists, channel modes and all. If you'd normally send it, cool. If not, I'd leave it out.

Yeah, the standard channel join burst is definitely required here, NAMES, TOPIC, etc.

Fixed, will push shortly.

sadiepowell · 2017-06-06T11:44:21Z

If a more specific error like ERR_CHANOPRIVSNEEDED can be sent in response to a rename request, what should servers do?

Yeah, thats what my implementation sends. I'll amend the spec in a bit.

sadiepowell · 2017-06-25T09:57:59Z

I think that should be everything other than deciding what numerics are to be used.

extensions/rename.md

kylef · 2017-09-07T21:35:05Z

extensions/rename.md

+## Implementation Considerations
+
+Server implementations MUST implement a fallback method for legacy clients.
+This method SHOULD involve sending the legacy client a `PART` message for the


Should the PART reason should contain the RENAME reason?

Yeah, i'll add that.

shouldn't it also contain the new channel name?

jwheare

Cool, I think anything in "considerations" sections that involves normative MUST, SHOULD or MAY directives would be better further up in an "Details" section, above examples.

I feel like considerations are usually for non-normative stuff, and implementation details, where I would use lowercase "might" instead of MAY.

Even the MAY stuff in here is probably normative rather than a consideration. E.g. specific error numerics reserved for moderation/permission stuff MUST be used but only if the server is actually performing the validation in question (it MAY choose not to).

extensions/rename.md

jesopo · 2018-11-05T10:21:21Z

Implemented in BitBot: bitbot-irc/bitbot@6d742f6a

RyanSquared · 2018-11-05T16:34:34Z

Implemented (minimally) in Moon Moon: wiseguiz/Moon-Moon@504e354

DanielOaks · 2018-11-06T17:08:19Z

This is implemented in Oragono (has been since 0.8.1 - 2017-06), but there's been a faaair few spec updates since then, will update to match the latest state of the PR.

jwheare · 2019-03-06T13:36:06Z

Implemented in IRCCloud too. Spec still needs some adjustment, my prior review requesting changes still stands fwict.

jwheare · 2019-03-11T10:07:22Z

extensions/rename.md

+
+## Implementation Considerations
+
+Server implementations MUST implement a fallback method for legacy clients. This method MUST involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc) and finally a `MODE` message to restore any prefix modes that the legacy client has applied to it.


Prompted by ergochat/ergo#300 (comment)

MODE isn't needed here. Prefix modes come from NAMES, and the channel mode is not normally included in a join burst, clients will request it on join.

(Edit to add a one-click suggestion)

Suggested change

Server implementations MUST implement a fallback method for legacy clients. This method MUST involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc) and finally a `MODE` message to restore any prefix modes that the legacy client has applied to it.

Server implementations MUST implement a fallback method for legacy clients. This method MUST involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc).

ilbelkyr · 2019-04-03T21:26:20Z

As mentioned on IRC, it's probably a good idea to explicitly mention the possibility of a RENAME message that only changes casing to ensure this is properly handled by clients.

I feel like the requirement to provide a PART/JOIN fallback might be relaxed in this situation since it may be more disruptive than silently starting to use a different casing in messages from the server, although that's certainly debatable.

RyanSquared · 2019-04-09T06:35:04Z

I feel like the requirement to provide a PART/JOIN fallback might be relaxed in this situation since it may be more disruptive than silently starting to use a different casing in messages from the server, although that's certainly debatable.

I think this would break clients that don't care about casing (such as my bot), whereas the PART/JOIN solution would most likely work on all clients.

sadiepowell · 2019-04-16T10:10:53Z

I think this would break clients that don't care about casing (such as my bot)

Such software is already broken as there is no guarantee the server will not change the case of a channel name (e.g. InspIRCd has a changecap module in extras).

jwheare · 2020-04-27T10:20:12Z

@SadieCat let me know if you want me to take this over to tidy it up? Not sure if it already allows edits from maintainers.

dequis · 2020-04-27T10:30:32Z

It says "from unknown repository" so I think you gotta close this PR and open a new one with a new source repo.

jwheare · 2020-06-08T12:15:52Z

Replaced with #420 (blaze it)

See <https://github.com/ircv3/ircv3-specifications/pull/420/files#diff-70e90beef48dc9cf5d784d1e179ea822R42> Moreover, make it so that clients that haven't negotiated `draft/rename` don't receive JOIN and PART messages. Rationale: <ircv3/ircv3-specifications#308 (comment)>

jwheare reviewed Jun 4, 2017

View reviewed changes

Zarthus reviewed Jun 4, 2017

View reviewed changes

extensions/rename.md Outdated Show resolved Hide resolved

DanielOaks reviewed Jun 5, 2017

View reviewed changes

jwheare added this to the Roadmap milestone Aug 9, 2017

jwheare added the protocol label Aug 9, 2017

jwheare added the Implementation needed label Aug 29, 2017

kylef reviewed Sep 7, 2017

View reviewed changes

jwheare requested changes Jan 22, 2018

View reviewed changes

extensions/rename.md Outdated Show resolved Hide resolved

extensions/rename.md Outdated Show resolved Hide resolved

extensions/rename.md Outdated Show resolved Hide resolved

extensions/rename.md Outdated Show resolved Hide resolved

sadiepowell added 3 commits November 4, 2018 10:20

Add the channel renaming extension.

8ee93ae

Weaken some rules from SHOULD to MAY.

496d4f3

Strengthen the recommended fallback method to a MUST.

4084a64

jwheare removed the Implementation needed label Mar 6, 2019

jwheare requested changes Mar 11, 2019

View reviewed changes

jwheare mentioned this pull request Jun 8, 2020

Channel renaming extension #420

Merged

jwheare closed this Jun 8, 2020

hhirtz mentioned this pull request Aug 4, 2020

Update draft/rename impl ergochat/ergo#1223

Merged


		## Implementation Considerations

		Server implementations MUST implement a fallback method for legacy clients. This method MUST involve sending the legacy client a `PART` message for the old channel name, with the rename reason as the part message if given, followed by the usual messages that would be sent if the legacy client had joined the new channel normally (`JOIN`, `RPL_TOPIC`, `RPL_NAMREPLY`, etc) and finally a `MODE` message to restore any prefix modes that the legacy client has applied to it.

Conversation

sadiepowell commented Jun 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jwheare left a comment

Choose a reason for hiding this comment

Uh oh!

sadiepowell commented Jun 4, 2017

Uh oh!

Zarthus commented Jun 4, 2017

Uh oh!

Uh oh!

Zarthus commented Jun 4, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RyanSquared commented Jun 5, 2017

Uh oh!

DanielOaks commented Jun 5, 2017

Uh oh!

DanielOaks Jun 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RyanSquared Jun 5, 2017

Choose a reason for hiding this comment

Uh oh!

DanielOaks Jun 5, 2017

Choose a reason for hiding this comment

Uh oh!

jwheare Jun 5, 2017

Choose a reason for hiding this comment

Uh oh!

sadiepowell Jun 25, 2017

Choose a reason for hiding this comment

Uh oh!

sadiepowell commented Jun 6, 2017

Uh oh!

sadiepowell commented Jun 25, 2017

Uh oh!

Uh oh!

kylef Sep 7, 2017

Choose a reason for hiding this comment

Uh oh!

sadiepowell Jan 22, 2018

Choose a reason for hiding this comment

Uh oh!

jesopo Nov 8, 2018

Choose a reason for hiding this comment

Uh oh!

jwheare left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jesopo commented Nov 5, 2018

Uh oh!

RyanSquared commented Nov 5, 2018

Uh oh!

DanielOaks commented Nov 6, 2018

Uh oh!

jwheare commented Mar 6, 2019

Uh oh!

jwheare Mar 11, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ilbelkyr commented Apr 3, 2019

Uh oh!

RyanSquared commented Apr 9, 2019

Uh oh!

sadiepowell commented Apr 16, 2019

Uh oh!

jwheare commented Apr 27, 2020

Uh oh!

dequis commented Apr 27, 2020

Uh oh!

jwheare commented Jun 8, 2020

Uh oh!

sadiepowell commented Jun 3, 2017 •

edited

Loading

Zarthus commented Jun 4, 2017 •

edited

Loading

DanielOaks Jun 5, 2017 •

edited

Loading

jwheare Mar 11, 2019 •

edited

Loading